A few weeks ago, I ve been busy at work updating the OFED packaging for OFED 1.5.2. We needed a version of the stack newer than what s (partially) available in Squeeze. As this has now been tested, we are all happy to contribute this work to Debian, courtesy of my customer, EDF. This morning, I ve pushed out packages for OFED 1.5.2 to the pkg-ofed SVN repository on Alioth. The packages should be made available in experimental at some point too, though a number of them will have to go through NEW. With this update, I ve cleaned up & updated the packaging where needed and also made two important changes that I need to highlight:

• package versions are now formed by the package version given in the BUILD_ID file shipped with OFED, postfixed with the OFED release they belong to. This gives, for instance, libibfoo 1.3.6-OFED-1.5.2-1. This makes it easier to identify OFED components and the OFED release they come from.
• InfiniBand driver modules for libibverbs have been renamed to ibverbs-driver-foo and the libibverbs modules are now installed to /usr/lib/ibverbs/drivers. This cleans up the packaging as the shared objects, that were previously shipped in libfoo packages, are not shared libraries but modules for libibverbs.

A number of libraries have changed their interfaces and bumped their soversions. libibcommon is gone, it has been folded into libibumad. The API/ABI between libibverbs and the IB driver modules has changed, so the new libibverbs comes with appropriate Breaks in place. Thanks to Beno t Mortier from pkg-ofed for his 2-day IB & OFED crash course that was instrumental in getting started with the OFED maze.

I ve just release pommed v1.35, adding support for the October 2010 MacBook Air machines. Kernel support for these machines has been submitted during the 2.6.37-rc cycle, so it will appear in 2.6.37 or 2.6.38 depending on maintainers, merge window and patch readiness. The machines have new keyboard assemblies (WellSpring IV and IVa) requiring new quirks in the HID layer, new trackpads, need sound & applesmc configurations of their own and the backlight module needs to know about them. So, make sure your kernel has all of that, otherwise your machine will be hard to use and pommed will not work at all. Update: #603395 filed against linux-2.6 with all the needed patches attached. It looks like we ll have all of this in Squeeze, thanks to our kernel team.

Apple released Remote 2.0, which doesn t work with forked-daapd. We are looking into it and trying to find out what the problem is. There are also more changes needed to support Remote 2.0 properly, so this will take some time. Remote 2.0 also introduces support for the iPad, with very different features and new requests. I don t have an iPad, so this won t be supported. For now, you should stick to the old version of Remote (1.3.3) until we get 2.0 working, at which point we ll probably pull support for the previous version in an attempt to maintain everybody s and the codebase sanity. In other news, I have a few changes pending that I want to get in before I cut a new release.

Hey, look, a release! I ve decided to start making tarball releases that make it easier to build forked-daapd, especially on embedded platforms. The tarballs come with the build system already generated (as should any real release) and they also contain pre-generated source files for the ANTLR3-based parsers used in forked-daapd. The pre-generated files will be used if antlr3 is not available for the build. I expect that pretty much everybody will end up using the generated files, given the feedback I ve had about ANTLR3. I hope this will also clear the misconception that forked-daapd depends on Java. I have expanded the installation instructions, making the distinction between building from the git tree and building from the tarballs. A few more fixes made it to this version since my last post, and Kai also put the final piece to the sort headers by adding sort headers to the song listings. Tarballs are available at http://alioth.debian.org/~jblache/forked-daapd/. Tarball integrity can be verified with GPG using the matching GPG signature file and my F5D65169 GPG key from the Debian keyring.

A number of things have happened in and around forked-daapd in the last month or so, so let s review the new features and the plan for Squeeze. On the features front, Kai Elwert has done a lot of work since July to implement missing features at the DAAP and DACP level to get better support for Remote:

• playlists can now be played from Remote;
• listings are sorted in a way that s closer to what you get from iTunes;
• sort headers are now generated when requested so Remote can display the A-Z quick access list.

Also, forked-daapd can now remember which speakers were selected before shutdown and attempts to automatically reselect these speakers the next time around. Speakers that were selected will be reselected if they appear at most 5 minutes after startup and the player isn t running at that time. On the Squeeze front, a viable snapshot of forked-daapd will release with Squeeze. This snapshot doesn t have all the Remote improvements listed above, although it s got the playlist support, can remember the speaker selection and includes bug fixes. My plan is to provide backports through backports.org once Squeeze is released and for as long as possible after that. There s always more in the works, so stay tuned =)

Thanks to the work of Mark Heily, both upstream and in Debian, this week saw the arrival of libdispatch in Debian. libdispatch is the userspace component of Apple s Grand Central Dispatch technology, designed to help write applications that really take advantage of multicore processors without having to fiddle directly with threads and locking (and getting it terribly wrong). To get that working on Linux, Mark wrote a userspace implementation of the pthread workqueues and a kqueue compatibility library (libkqueue). He also packaged the Blocks runtime (libblocksruntime) for Debian so as to build libdispatch with Blocks support. That means code using libdispatch must be built with CLang (or llvm-gcc-4.2) rather than gcc, as getting Blocks support in gcc in the near future looks highly improbable. On Mac OS X and FreeBSD, a kernel-based implementation of the pthread workqueues is used; we don t have that for Linux yet. The all-userspace implementation we have at the moment works really well; there are some caveats, though, but that s no reason for not starting to play with libdispatch right now! Try it out, it s great. Thanks again, Mark!

Following the update of antlr3 in unstable, I have now uploaded forked-daapd to Debian. For now, and until the new version of antlr3 is ready to migrate to testing, forked-daapd will only be available in experimental. I have also uploaded the ANTLR v3 C runtime (aka libantlr3c) to unstable. It s currently blocked from migrating to testing, until antlr3 is ready to migrate. Hopefully, the issues affecting antlr3 3.2 in unstable will be resolved soonish and all of this will migrate to testing and be part of Squeeze.

I ve been working on this for a few months now; it s taken quite some time because I wanted to do it right and deliver something better than what already existed in the OpenSource world as far as that particular technology was (not) concerned. So here it is:

AirTunes v2 UDP streaming forked-daapd can now do streaming to multiple AirTunes devices (as well as the local soundcard) and can be controlled from Remote (and, ideally, from anything that speaks DACP). I m releasing this early while the paint is still wet and not everything works on the DACP-side of things. Case in point, while playing a song or an album is supported, playing a playlist isn t. There s some work needed on this particular feature, and it ll get there eventually. There have been a couple of other changes in the codebase in recent weeks too; details after the jump. Implementing AirTunes v2 has been quite fun and, in addition to releasing the forked-daapd code today, I ve also taken the time to write down my findings about the protocol so others can experiment with it. This documentation is by no means exhaustive nor complete as far as the protocol goes; if you find out anything I haven t, let me know so I can update this document. Let s review the recent changes in the forked-daapd codebase over the past few weeks. AirTunes v2 You can now use Remote from your iSomething together with your AirTunes devices and forked-daapd to listen to your library. As mentioned above, playing a playlist is not supported; I have a few things to sort out before this can work and I suspect this will bring changes not only to the DACP interface but also to other parts of the code. So, stay tuned. forked-daapd supports synchronized playback to multiple AirTunes devices together with the local soundcard if so desired. You can expect the AirTunes devices to be in sync with each other, but the soundcard will usually run in circles around them. It looks like AirTunes plays sound a bit slower than 44.1 kHz; not a big deal, though, as AirTunes will catch up periodically and the desync, while it can be noticeable, isn t big (ie we re not talking seconds, not even one full second). Make sure your network can handle the load, as streaming to a single AirTunes device requires in excess of 1.6 Mbps (1.8 Mbps is actually closer to the real thing). Local audio output is supported via ALSA and OSS4, although note that the OSS4 code hasn t been very well tested. I intend to test and debug it fully at a later date, but feel free to beat me to it and send patches. Also note that, while there is code for FreeBSD in the player/streaming part of forked-daapd, it doesn t work well at all. The streaming code needs a timer with a higher resolution than kqueue/kevent has to offer, and I haven t found anything as capable as timerfd. So it s there, but it s broken. Read on about FreeBSD support. Metadata scanning Several fixes and enhancements have been made to the filescanner so it picks more and better metadata. Format-specific tagnames have been added to work around ffmpeg s limitations. Using a recent enough ffmpeg version (anything after mid-december 2009) will work best, especially for MP3 files. SQLite concurrency fixes The database code has been reworked to handle concurrency on the database. Issues with locked tables (or the whole database) were noticed pretty easily with big libraries when accessing forked-daapd during the library update after startup. On uniprocessor machines, this was even easier to hit. This, however, comes with new requirements for SQLite3: you ll now need SQLite3 v3.5.0 at least and it must be built with the unlock notify API enabled. Not all distributions ship SQLite3 with the unlock notify API enabled, so you may need to do a rebuild. Debian, for instance, doesn t; this is #579266. A word about FreeBSD support I m giving up on FreeBSD support. The streaming code doesn t work on FreeBSD due to timer issues, and I don t intend to fix it. I also don t intend to invest much time in porting future features to FreeBSD; if I can make it work, then fine, otherwise, too bad. Someone needs to step up if there s interest in having forked-daapd work on FreeBSD.

When I got my Mac Mini, one of the very first things I did was to test the Debian build of rEFIt on the machine, given the EFI firmware is x64 on the newer machines whereas it s ia32 on my MacBookPro; it was the very first time I could test the x64 build. And the results weren t good: some images couldn t be loaded, and it all seemed to be random. Disabling optimization in both GNU EFI and rEFIt for the x64 builds helped somewhat, at least it made rEFIt reliable enough to be usable. Now, with this new release, I started getting error messages, requiring a key press before the menu would be displayed. It s annoying but it s also very helpful as I now had an error message to work with, and even if the error message wasn t reliable, it would still point me to some part of the code. The message was: Invalid argument. On x64, the use of a call wrapper is mandatory because the EFI x64 calling convention doesn t match the calling convention of the ELF executables we re building and later disguising as EFI executables. The call wrapper has always been the prime suspect in this issue, it d be an obvious candidate for anyone looking at this issue. Today, digging into the issue with some new data, I realized what the problem was: when using the call wrapper, all arguments need to be of the UINT64 type. That s the type the call wrapper uses when extracting the arguments from its va_list. Introduce some more macros on top of the call wrapper, build, test: voila, it s fixed! That was tricky one. Let s sum it up for the search engines: all the arguments to the EFI interface called through uefi_call_wrapper() in GNU EFI need to be cast to UINT64. rEFIt 0.14-1, available in unstable in a couple hours. Next, I ll see if I can reenable optimization in both GNU EFI and rEFIt.

I ve just released pommed v1.32, a minor maintenance release for the 12 PowerBook G4. I ve just realized that I did not post an announce for pommed v1.31 a while back, which was also a maintenance release, adding support for the MacBookPro5,4 (15 June 2009) and the latest wireless keyboard.

After weeks of trying to get around to doing that, I am finally starting the process of replacing my 10-year old 1024 bits DSA key with a shiny new 4096 bits RSA key. The old key ID is F5D65169, the new key ID is FA1E5292; it s available from the keyservers or my website. I have put up a transition document, signed with both keys; if you ve signed my old key, grab it, verify it and if all is OK on your end, please sign the new key. You ll notice that one of the old UIDs did not make it to the new key; that s because I m not using that email address and don t actually intend to use it in the future. Thanks!

A few weeks ago, I ve added support for Remote, Apple s iPhone application for controlling iTunes remotely. Here, support means Remote can be paired with forked-daapd and can be used to browse the library. And that s it, for now. At this point, there won t be much visible activity on forked-daapd for some time. I m working on a couple of things, but they take time and they require a lot of new code. So, for a couple weeks now, I ve been working on that. I have some code outside forked-daapd that is starting to work well, but it s not there yet, far from it. Then it ll have to be integrated into forked-daapd, which means a lot of new code there too. Bug fixes will still happen in the meantime, and some smaller new features may also appear before the Big Thing . So if you find or encounter bugs, feel free to report them still. If you have patches or ideas you want to discuss, feel free too. As I wrote to a couple people by mail already, good things come to those who wait or contribute. With all that, I ve updated the Debian packages, given that there won t be important changes for a while; I hope they re useful to some of you out there. Note that I m making an amd64 binary package available alongside the source package; it s built on a current Debian unstable system, but if that s not suitable for you, in terms of dependencies or architecture, you can trivially build a suitable binary package from the source package. As a reminder, I have packages of the ANTLRv3 C runtime too. I ve also added antlr-3.1.3.jar there, in case you need it and can t find it at the upstream download site.

Ten years ago, pretty much to the day, I was installing my first Debian system, a frozen Potato, using a release-candidate version of the boot-floppies. A few days later, I was reading the Policy, New Maintainer s Guide and Developer s Reference while building my first package. It s been a fun ten years, with ups and downs, and I m looking forward to what s coming next.

Mostly an update to my previous post on the subject, I ve just completed the FreeBSD port. It also builds and runs on GNU/kFreeBSD, by the way. The filescanner for forked-daapd on FreeBSD is now up to par with its Linux counterpart, as much as possible. Contrary to the latter, it will lose some metadata (play count, for instance) when files get moved around, because it s not possible to track moves and renames accurately. It also performs more rescans than the Linux/inotify implementation. Still, it works just as good. On a related note, the machine I tried to install FreeBSD 8.0 on and finally ended up installing GNU/kFreeBSD on just seemingly committed suicide. I m not sure what message it s trying to send me. It s previously been my main workstation for the best part of 10 years, so this is a bit sad. At least I found some bugs in the process and fixed some too:

• 2 bugs in forked-daapd, one of them a crasher,
• a bug in Avahi on kFreeBSD,
• a bug in GRUB2 as used on the kFreeBSD daily d-i images.

Not bad, is it?

Since I released forked-daapd, I ve got a couple of emails about porting it to FreeBSD. Apart from isolating and reimplementing the parts of the code using signalfd and inotify, there isn t much work to do beside taking care of the usual libc/platform issues. However, when you don t know the codebase and don t know the APIs you re replacing, it makes it a bigger job. So, I ve just spent a day going through FreeBSD documentation, installing FreeBSD 8.0 in qemu (because it wouldn t install on my spare machine due to a bootloader issue that s at least 5 years old ), and started porting the codebase. A dozen or so commits later, forked-daapd builds and runs on FreeBSD. With one caveat: the filescanner doesn t update the database on the fly when the library directory is modified. While I ve put in support for kqueue/kevent to replace inotify, it s only a stub for now. Someone will have to write the code to actually act on the events and trigger the rescans/database updates. kqueue/kevent delivers a lot less information compared to inotify, which means there s a lot of work needed to track renames and moves. And I didn t feel like doing it. So, FreeBSD users: send patches! :)

I ve spent the last week packaging VMware Workstation 7.0.0 at work. Looking around on the net, I ve been unable to find anything helpful about packaging this new version, so it seems nobody s got around to packaging it yet. I ve asked our customer for its approval for releasing our packaging scripts to the community and got it, so here are our packaging scripts for this version, courtesy of EDF. See the instructions in debian/README.source for what has to be done to turn it into a full source package. The packaging is based on our previous 6.5.2 packaging, which was itself based (partially, at least) upon the Gento 6.5.2 ebuild. It uses a tweaked vmware-installer to install the products to debian/tmp, then makes use of the vmware-installer database to populate the packages. I think this method should work with any VMware product using vmware-installer 1.1. Packages have been built and tested on Etch and Lenny. Hope it helps! Bugs, comments, questions to the email address listed as Maintainer in debian/control, please :-)

Over the past weeks, a couple of contributors sent me fixes and new features for forked-daapd. Thanks to you all! The biggest change is the addition of TV shows metadata as found, for instance, in TV shows bought on the iTunes store. Together with the added support for FrontRow and QuickTime clients, this means forked-daapd is a lot more able at streaming video files than it ever was. Kudos to Ace Jones for his work! Note, however, that you ll need a patched version of ffmpeg to pick up the TV shows metadata from your MP4 files. At the time of writing, the patches have not landed into ffmpeg upstream yet, and it s a bit unclear when this will happen. Contact Ace for the patch and instructions, see the commits in the git tree for his email address. Git tree on Alioth: http://git.debian.org/?p=users/jblache/forked-daapd.git (git URIs on the page)

I ve just bought a Packard Bell OneTwo (M3700), a 600 Euros all-in-one computer with a 20 multipoint touch screen (there are bigger models with 23 touch screen, wifi and some other options). This machine will be used to run OpenBravoPOS, a free (libre) point of sale software. So far, I think this machine is just perfect for the job. Getting it to run smoothly under Linux is not a walk in the park, however. There are some quirks and some assembly is required, but once you re done (that takes a couple of hours at most once you ve got all the info, which you have if you re reading this) this machine is just great. It s fast, with a 2.1 GHz Pentium Dual-Core (T4300) CPU, 4 GB of RAM, an Intel GM45 GPU with up to 256 MB of shared RAM, gigabit networking, a fast 320 GB SATA disk and a combo DVD-drive (not a slot-in, too bad). The screen is nice, and the touchscreen is incredibly smooth, precise and sensitive. The sound is good, the webcam is great and it works out of the box, too! Update: added a note about the card reader. Before you go Enter the BIOS and bump the amount of memory allocated to the GPU to 256 MB. By default, the machine ships with only 64 MB allocated to the GPU, which is low and ridiculous considering it is equipped with 4 GB Installing Debian Forget about installing Lenny with debian-installer on this machine. The standard installer with its 2.6.26 kernel doesn t support the network interface properly. Upgraded installer images with 2.6.28 or 2.6.30 kernels end up locking the machine solid before the first installer screen. Your best friend: System Rescue CD. Your other best friend: debootstrap. Before rebooting, install the 2.6.30 kernel from backports.org. It works like a charm, even if the 2.6.30 on the upgraded installer locked up solid. Go figure :) While you re at it, install X from Testing. You need a recent enough version of the intel driver that will support the GM45 chip. Configuring X This is the first and the biggest quirk on this machine. The LCD is actually wired up to both the VGA and the LVDS outputs on the graphic card, and advertises different resolutions on both. The native resolution (1600 900 on this model) is only advertised on the LVDS output. While fiddling with X, it becomes obvious that the VGA output is used as the boot video device. If you disable the output in X with xrandr, you loose the text consoles. My un(?)educated guess is that this setup allowed them to use a standard desktop PC BIOS instead of using a more expensive laptop BIOS. I may be wrong, but that s pretty much the only thing that makes sense to me. Anyway. If you want X to work properly, you ll have to tell it to ignore the VGA output entirely.

Section "Device"
 Identifier  "Intel X4500"
 Option  "Monitor-LVDS"  "Panel on LVDS"
 Option  "Monitor-VGA"  "Panel on VGA"
EndSection
Section "Monitor"
 Identifier  "Panel on LVDS"
EndSection
Section "Monitor"
 Identifier  "Panel on VGA"
 # The LCD panel is wired up on both VGA and LVDS
 # Ignore the VGA output as far as X is concerned
 Option  "Ignore"  "True"
EndSection

If you don t tell X to ignore the VGA output, you ll end up with a mirror setup and your desktop will use the smallest size so as to fit on both monitors. It isn t pretty, it s plain silly and we want those 20 used fully, dammit! See the full xorg.conf. Touch screen The touch screen is an infrared multipoint touch screen from Quanta. No kernel driver is needed, only an input driver for X is required. Start by adding an udev rule like this one:

SUBSYSTEM=="usb", ATTRS idVendor =="0408", ATTRS idProduct =="3000", SYMLINK+="usb/quanta_touch"

The touch screen will now appear as /dev/usb/quanta_touch, which is more handy and stable than /dev/usb/hiddevN. Grab xf86-input-hidtouch from HidTouch Suite on SF.net, and apply this patch. The aim of the patch is to ignore anything but the first reported pressure point. The touch screen is a multipoint touch screen and as such can report 2 or 3 (not sure) pressure points at the same time. The driver can t handle that yet. The patch also fixes a bad comment and an API difference with newer X versions. Build and install the driver, then edit xorg.conf:

Section "InputDevice"
 Identifier  "Optical Touch Screen"
 Driver  "hidtouch"
 Option  "SendCoreEvents"  "true"
 Option  "ReportingMode"  "Raw"
 Option  "Device"  "/dev/usb/quanta_touch"
 Option  "PacketCount"  "13"
 Option  "OpcodePressure"  "852034"
 Option  "OpcodeX"  "65584"
 Option  "OpcodeY"  "65585"
 Option  "CalibrationModel"  "1"
 Option  "CornerTopLeftX"  "0"
 Option  "CornerTopLeftY"  "0"
 Option  "CornerTopRightX"  "1600"
 Option  "CornerTopRightY"  "0"
 Option  "CornerBottomLeftX"  "0"
 Option  "CornerBottomLeftY"  "900"
 Option  "CornerBottomRightX"  "1600"
 Option  "CornerBottomRightY"  "900"
 Option  "CornerScreenWidth"  "1600"
 Option  "CornerScreenHeight"  "900"
EndSection

There you are. Working touch screen! Credit: the above touch screen setup instructions, including the patch (which I reworked slightly ) were taken from this post on the Ubuntu-fr.org forum. The instructions cover the Packard Bell Viseo 200T touch screen, which is identical to what s used on the OneTwo. If you re looking for a 20 touch screen, go for it; at 200 Euros it s a good deal. Sound The Realtek ALC268 codec as used in the OneTwo isn t properly supported yet, however using model=acer-aspire works for the integrated speakers and the headphone jack. Line out and the integrated microphone do not work. Webcam The webcam is a UVC webcam and the image quality is stunning. I m seriously considering stealing that webcam to replace the iSight in my MacBook Pro. It works out of the box without any firmware. Quite a good surprise :) Flash card reader The integrated flash card reader also works out of the box, for the card formats supported by Linux.

Pommed v1.30 is a bug fix release fixing two small bugs:

• a crasher bug on PowerMac machines
• a bug in the sysfs backlight driver, mishandling brightness values with more than 3 digits

If you are running on a recent MacBook/MacBook Pro with a recent kernel, you ll probably want to upgrade to this release.

pommed v1.29 is a bugfix release, kind of. The fix is an architectural one related to the video mode switch feature. When pressing the video switch key, your graphical pommed client of choice checks which VT its X server is running on and whether this VT is the active one before executing your video mode switch script. To check that the VT is currently active, it is necessary to open one VT (we use the one our X server is running on) and perform an ioctl() call on it. Depending on your setup (login manager or startx, basically), your user will or will not have any right on the device node associated to the VT. Which means the VT state checking code would always fail in some setups. This is now fixed by moving that code into pommed itself, with a DBus method for the clients to call. You ll need to update both pommed and the clients for this to work, for obvious reasons.